Follow-up to #720 (suggestion #3 — structural route coverage, distinct from the ranking fix). Closes #747.

Why

GoFrame binds routes reflectively, so there's no literal /chat string and no call edge from path → controller method:

// api/chat/v1/chat.go — the route lives in a struct tag on the request type
type ChatReq struct {
	g.Meta `path:"/chat" method:"post"`
	Content string `json:"content"`
}
// the handler is the controller method named after the request type (ChatReq -> Chat)
func (c *ControllerV1) Chat(ctx context.Context, req *v1.ChatReq) (*v1.ChatRes, error) { ... }

Today "where is this route registered / which method handles it" can only be answered lexically — route-registration symbols have nothing to win on.

What

Extend goResolver.extract (src/resolution/frameworks/go.ts) with a GoFrame pass:

• read the g.Meta struct tag (path: + method:, defaulting to ANY when method: is absent) → a route node, identical in shape to the existing Gin/mux route nodes, and
• link that route to the controller method by GoFrame's naming convention (request type with the Req suffix dropped, ChatReq → Chat) via a references edge — same shape as the existing route→handler edges.

The route node and its method edge are emitted together: a g.Meta whose type doesn't follow the …Req convention (or has no path:) is skipped rather than left as an orphan route node, per the "partial coverage is worse than none" guidance.

Scope / follow-ups (intentional)

• Relative path only. Only the path: from the tag is captured (/chat), not the s.Group("/api", …) prefix that GoFrame prepends. The route node + method edge are still complete and useful; joining the group prefix (cross-file) is a clean follow-up.
• Method resolution. The route→method references edge resolves through the same name-resolution path as the existing Gin/mux route handlers. There's no GoFrame-specific resolve() pattern, so a method name resolves like any PascalCase ref; a dedicated method-kind resolution pattern is possible follow-up hardening (same risk profile as today's route-handler refs).

Tests

Two unit cases added to goResolver.extract in __tests__/frameworks.test.ts (mirroring the existing Gin/mux/Rust route-extraction tests): g.Meta with method:"post" → POST /chat + Chat edge; method-less g.Meta → ANY /list + List edge. Both assert the edge binds to the route node id.

Validation

• npm run build — clean (tsc).
• npx vitest run __tests__/frameworks.test.ts — 96 passed, no existing route tests broken.
• Verifiable with pure inline-Go string fixtures (the resolver is regex-over-source) — no Go toolchain needed; happy to also run the real small/medium/large GoFrame-repo validation from codegraph/CLAUDE.md if you want it in the PR.